For my CNC Controller app, I want to have a thread running on the DSP that will field a wide range of different, simple requests - coolant on/off, spindle control, goto tool change position, etc. - under user control. This makes the GUI application code for many functions little more than sending a message to the DSP, and all the function customization can then be done in DSP code. The most obvious (at least to me) way of handling this is to have a thread running which polls a pre-defined range of Persist vars, the first of which would be a "command" code. When this word is set to a non-zero value the DSP code then looks at the other words for any parameters needed for the requested command, executes the command, clears the command word, and wait for the next command. Commands would be queued on the PC side, and metered out by a timer handler.

Is this reasonable, or is there a better way to handle this?

Regards,
Ray L.

---

From: himykabibble
Sent: 1/15/2012 4:57 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Generic Function Handler....

Brad,

Agreed again, but here, too, I'm just trying to get some base functionality going ASAP, using mostly existing code.

Not sure exactly what you mean by "Also I think events are a much more efficient and robust state change notification mechanism.".... Is there already something in dotNet that could be used?

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, brad murry <bradodarb@...> wrote:
>
> This a similar "mini-framework" that I tried to request collaboration on a few weeks back. IMHO dynomotion is in desperate need of some out of the box functionality like this. I would love to collaborate with others to this end, so count me in if you want help. To be truly successful, we would likely need 1 or 2 goodies from Tom to make it gel right with minimal effort from the end user. A framework like this coupled with the universal homing routine would be a large leap in the right direction and lower the barrier of entry for applications from typical 3 axis CNC to custom automation projects.
>
> Also I think events are a much more efficient and robust state change notification mechanism.
>
> The ideal result in my mind would be to have these mini c frameworks tied in to the .net APIs for super clean integration.
>
> 2c,
>
> -Brad Murry
> ________________________________
> From: himykabibble
> Sent: 1/15/2012 4:57 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Generic Function Handler....
>
> For my CNC Controller app, I want to have a thread running on the DSP that will field a wide range of different, simple requests - coolant on/off, spindle control, goto tool change position, etc. - under user control. This makes the GUI application code for many functions little more than sending a message to the DSP, and all the function customization can then be done in DSP code. The most obvious (at least to me) way of handling this is to have a thread running which polls a pre-defined range of Persist vars, the first of which would be a "command" code. When this word is set to a non-zero value the DSP code then looks at the other words for any parameters needed for the requested command, executes the command, clears the command word, and wait for the next command. Commands would be queued on the PC side, and metered out by a timer handler.
>
> Is this reasonable, or is there a better way to handle this?
>
> Regards,
> Ray L.
>